1. Field of the Invention
The present invention relates to the formation and use of secure network connections. More specifically, the present invention relates to forming secure network connections for devices located within different private networks.
2. Description of the Related Art
Virtual Private Networks (“VPNs”) exist which enable private communications among devices associated with a given VPN, even if some or all of the communications are transmitted over a public network. Most VPNs are broken down into categories that reside in different layers of the well-known Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. In particular, the Network and Link Layers of the TCP/IP protocol suite (i.e., layers 3 and 2, respectively) are examples of layers commonly used to establish VPNs.
With respect to Network-Layer VPNs, there are several known methods for construction of such VPNs. As a first example, “route filtering” can be implemented to control route propagation such that only certain networks receive routes for other networks within their own community of interest (i.e., VPN).
Route filtering is based on the proposition that some network subset of an underlying IP network supporting the VPN (such as the Internet) actually forms the VPN. Routes associated with this network subset are filtered such that they are not announced to any other network(s) connected to the network subset forming the VPN. Conversely, no other non-VPN route is announced to the network subset.
Privacy of services on a network-layer, route filtering VPN is implemented by restricting any of the VPN hosts from responding to packets which contain source addresses from outside the VPN. Such restrictions are based on access control lists (“ACLs”), which are tables that tell a device which access rights each user has. That is, an ACL is a list of entries that grant or deny specific access rights to individuals or groups.
Conventional network-layer, route filtering VPNs, however, have various difficulties associated therewith. For example, such an arrangement can be misconfigured such that it erroneously accepts packets which it should not, and/or rejects packets that should be accepted. Another problem with route filtering is that, when implemented behind a gateway or firewall device, subscriber networks can define a router external to the gateway/firewall as the default router, so that users of the VPN behind the gateway/firewall can reach external networks as long as they know the default router address (even if it is not advertised). Additional shortcomings of this technique include administrative mistakes, a static nature of the design and limitations on the security provided. In addition, the complexity for defining and maintaining all the rules is very high, so that the technique does not scale very well or very easily.
As a final point related to network-layer, route-filtering VPNs, connection between two different VPNs (i.e., inter-VPN connectivity) requires the network to route externally-originated packets to the VPN interconnection point. If the packets are admitted into the VPN at the interconnection point, the same packets may be passed back across the network to the ultimate VPN destination address. Thus, this interconnection point is a very sensitive point in the security design of interconnected VPNs.
A second type of network-layer VPN is built using tunneling protocols. Generic Routing Encapsulation (GRE) is a network-layer tunneling protocol used to construct VPNs (Layer 2 tunnelling protocols, such as Layer 2 Tunnelling Protocol (L2TP) and Point-to-Point Tunnelling Protocol (PPTP) are also known and are discussed in more detail below).
GRE tunnels are configured between a source (ingress) router and a destination (egress) router, such that packets designated to be forwarded across the tunnel are further encapsulated with a new header (the GRE header), and placed into the tunnel with a destination address of the tunnel endpoint (the new next-hop). When the packet reaches the tunnel endpoint, the GRE header is stripped away, and the packet continues to be forwarded to the destination, as designated in the original IP packet header.
In the GRE tunnelling protocol, routing for the VPN is isolated from routing of the customer. The VPNs can reuse the same private address space within multiple VPNs without any cross impact, providing considerable independence of the VPN from the customer network.
Various difficulties exist with respect to implementing the GRE tunnelling protocol. For example, GRE tunnels must be manually configured, which leads to excessive administrative overhead. Also, privacy of the network is an area of concern, because the tunnel is still vulnerable such that privacy is not absolute. Additionally, packets that use GRE formatting can be injected into the VPN from third-party sources. Moreover, it is necessary to deploy ingress filters that are aligned to the configured tunnel structure in order to ensure a greater degree of integrity of privacy of the VPN. Finally, it is also necessary to ensure that Customer Premises Equipment (CPE) routers are managed by the VPN service provider, because the configuration of the tunnel end-points is a critical component of the overall architecture of integrity of privacy.
As a final example of a network-layer tunnelling technique, IP Security (IPSec) has been developed. IPSec is a flexible framework for providing network-layer security. Earlier security protocols often protected only a portion of an end-to-end path, or forced the imposition of the same protection everywhere along the path. IPSec, in contrast, provides complete end-to-end network layer security, while giving the opportunity to tailor the security coverage on a segment-by-segment basis along any given path. IPSec protocols support data origin authentication, data integrity, data confidentiality, encryption key management, and management of security associations. Within the IPSec framework, a company can configure secure end-to-end solutions that can accommodate both locally attached users and remote-access users, and can support communications both within the company and between different companies.
IPsec encrypted tunnel mode, nonetheless, still leaves the tunnel ingress and egress points vulnerable, because these points are logically part of the host network as well as being part of the unencrypted VPN network. Any corruption of the operation, or interception of traffic in the clear, at these points will compromise the privacy of the private network. In the tunnel mode, however, traffic that transits the encrypted links between participating routers is considered secure.
In addition to network-layer VPNs, there also exist conventional link-layer VPNs. For example, link-layer protocols such as Frame-Relay or Asynchronous Transfer Mode (ATM) allow building VPNs as a set of Private Virtual Circuits (PVCs). The VPNs built are not generally fully-meshed (i.e., each of the VPN devices is not necessarily capable of communicating directly with all of the other VPN devices). Rather, they are only partially meshed, or use a Hub model. Although robust and simple, these protocols are not easily scalable, since any peer-to-peer connection is a dedicated PVC that needs to be configured manually.
One method of addressing these scaling issues in link-layer VPNs is to use VPN labels within a single routing environment, in the same way that packet labels are necessary to activate the correct per-VPN routing table in network layer VPNs. The use of local label switching effectively creates the architecture of the well-known Multi-protocol Label Switching (MPLS) VPN. The architectural concepts used by MPLS are generic enough to allow it to operate as a peer VPN model for switching technology for a variety of link-layer technologies, and in heterogeneous Layer 2 transmission and switching environments. MPLS requires protocol-based routing functionality in the intermediate devices, and operates by making the transport infrastructure visible to the routing.
MPLS VPNs have not one, but three key ingredients: (1) constrained distribution of routing information as a way to form VPNs and control inter-VPN connectivity; (2) the use of VPN-IDs, and specifically the concatenation of VPN-IDs with IP addresses to turn (potentially) non-unique addresses into unique ones; and (3) the use of label switching (MPLS) to provide forwarding along the routes constructed via (1) and (2).
Numerous approaches are possible to support VPNs within an MPLS environment. In the base MPLS architecture, the label applied to a packet on ingress to the MPLS environment effectively determines the selection of the egress router, as the sequence of label switches defines an edge-to-edge virtual path. The extension to the MPLS local label hop-by-hop architecture is the notion of a per-VPN global identifier, which is used effectively within an edge-to-edge context. This global identifier could be assigned on ingress, and is then used as an index into a per-VPN routing table to determine the initial switch label. On egress from the MPLS environment, the VPN identifier would be used again as an index into a per-VPN global identifier table to undertake next-hop selection.
In another approach to supporting VPNs within an MPLS environment, a Provider Edge (PE) router having a plurality of logical routers is configured such that each logical router corresponding to one VPN can be implemented with an entity of a routing protocol between PE routers whose processing is based on VPN Routing and Forwarding (VRF) tables. Based on the route information of a VRF table in a PE router, user traffic received from a CE (Customer Equipment) device or another PE router is forwarded to another CE device or PE router via an access or logical link respectively. For the dynamic routing service, a PE router distributes route information inside user sites, which is received from a CE device or another PE router, to another CE device or PE router using routing protocol between PE routers. A PE router implements one or more logical (i.e. “virtual”) routers. It is usually located at the edge of an SP (Service Provider) network.
Finally, tunneling techniques for link-layer VPNs also exist. For example, Virtual Private Dial Networks (VPDN) exist which use layer 2 tunnelling techniques. There are three principal methods of implementing a VPDN: Layer 2 Tunnelling Protocol (L2TP), Cisco Layer 2 Forwarding protocol (L2F) from which L2TP was derived, and Point-to-Point Tunnelling Protocol (PPTP) tunnels. Such tunnels represent VPNs that can be static or dynamic tunnels with, in some cases, a preliminary authentication phase.
In short, various solutions have been put forward to achieve different levels of network privacy when building VPNs across a shared IP backbone. Many of these solutions require separate, per VPN forwarding capabilities, and make use of IP or MPLS-based tunnels across the backbone. Also, within a VPN domain, an instance of routing is used to distribute VPN reachability information among routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability.
Generally speaking, then, a VPN can take several forms. A VPN can be between two end systems, or it can be between two or more networks. A VPN can be built using tunnels or encryption (at essentially any layer of the protocol stack), or both, or alternatively constructed using MPLS or one of the “virtual router” methods. A VPN can consist of networks connected to a service provider's network by leased lines, Frame Relay, or ATM. As a final example, a VPN can consist of dialup subscribers connecting to centralized services or to other dialup subscribers.
Regardless of which of the above techniques (or other known techniques) is used to form a VPN, it should be understood that network security is a concern. In fact, network security is a concern in many contexts aside from VPNs, and, in general, increasing use of remote access over public networks and Internet access for inter-business communication are major driving forces behind the evolution of security technology. In particular, public-key certificates (discussed in more detail below) and dynamic passwords are two technology areas that are growing rapidly to meet the security needs of today's networked environment. In the VPN arena, these security technologies are well-used in VPNs based on IPsec, but are not as advantageous when used in conjunction with other VPN technologies.
Many techniques for network security revolve around the use of a firewall, which is generally known as a combination of hardware and software used to implement a security policy governing network traffic between two or more networks, some of which may be under administrative control (e.g., organizational networks) and some of which may not be under administrative control (e.g., the Internet). A network firewall commonly serves as a primary line of defense against external threats to an organization's computer systems, networks, and critical information. Firewalls can also be used to partition networks or isolate/interconnect VPNs. Firewalls use various decision-making processes, such as packet filtering, application proxies and dynamic filtering (stateful inspection), to filter out undesirable packets from entering/exiting the protected network. Such decision-making processes are discussed in more detail below.
In addition to these security-related filtering functions, firewalls can also perform routing functions that are associated with the network being protected and that are conventionally associated with a separate/individual router. Routing is the process of deciding the disposition of each packet that a routing device handles. This applies to incoming packets, outbound packets leaving a network for external destinations, and packets being routed among internal networks. Ultimately, there can be only two dispositions of packets: forward or discard. The routing mechanism decides between these two using the destination IP address in the packet header. This decision process is governed by a data structure called the routing table.
A firewall system's routing configuration reflects its view of the topological configuration of the networks to which it is attached. A routing configuration that reflects the network topology is generally used so that the firewall will be able to deliver legitimate packets to their desired destinations. Most firewall systems' routing configurations rarely change, and are static. The static nature of the routing configurations stems from the fact that routing topology changes may create conflicts between routing and filtering policies for certain filter rules.
Each network to which a firewall system is attached has a procedure to obtain new IP addresses. For the Internet, this is obtained from the Internet Service Provider (ISP) that connects to the firewall. For internal networks, a dedicated IP address should be given from within the organization. If dynamic IP addresses are used, additional authentication techniques may be required, as is known.
A firewall system's routing table contains a list of IP network addresses for which the firewall system is intended to provide routing services. Each row of the table describes one network. The index used to access a row in the table is the destination network address of the packet currently being routed. If table lookup is successful, the table provides either the address of the next router to which to send the packet or the interface to use to send the packet out. That next router is used as the intermediate destination and the packet is forwarded there. If the table lookup fails, the packet is discarded. An Internet Control Message Protocol (ICMP) “unreachable” message may be returned to the source indicating that the packet was undeliverable.
Regardless of the routing technique used, the routing mechanism is usually not used to implement security policy. That is, a routing mechanism is often considered too dynamic and unreliable to perform security functions. Routing functions and supporting structures are primarily designed to route packets efficiently and reliably, not securely. Therefore, filtering techniques that can be implemented in connection with operation of a firewall (and/or router) for security purposes exist, and examples of these (as referred to above) are packet filtering, application proxies, and dynamic filtering (stateful inspection).
Packet filtering on routers is used to allow, to the extent possible, only authorized network traffic. Packet filters specify packets to filter (discard) during the routing process. These filtering decisions are usually based on contents of the individual packet headers (e.g., source address, destination address, protocol, port). Some packet filter implementations offer filtering capabilities based on other information; these implementations are discussed in more detail in connection with stateful inspection described below.
Generally speaking, packet filtering routers offer the highest performance firewall mechanism. However, they are harder to configure because they are configured at a lower level, requiring a detailed understanding of protocols.
Packet filtering is the process of deciding the disposition of each packet that can possibly pass through a router with packet filtering. For simplicity's sake, it can be assumed that there are only two dispositions: accept and reject. IP filtering provides the basic protection mechanism for a routing firewall host, allowing a determination of what traffic passes through based on the contents of the packet, thereby potentially limiting access to each of the networks controlled by the firewall router.
The criteria used in each filtering rule for determining the disposition can be arbitrarily complex. For a router with packet filtering, there may be multiple points in the routing process where the rules are applied; typically, for arriving packets, they are applied at the time a packet is received and, for departing packets, they are applied immediately before a packet is transmitted. There may be different rule sets at each point where filtering is applied. If the entire security policy can be implemented in packet filters, then other firewall mechanisms may not be required. If some elements of the filtering policy cannot be implemented with packet filters, then additional firewall mechanisms such as proxies may be necessary.
An application proxy is an application program that runs on a firewall system between two networks. The firewall host on which the proxy runs does not necessarily need to be acting as a router. When a client program establishes a connection “through” a proxy to a destination service, it first establishes a connection directly to the proxy server program. The client then negotiates with the proxy server to have the proxy establish a connection on behalf of the client between the proxy and the destination service. If successful, there are then two connections in place: one between the client and the proxy server and another between the proxy server and the destination service. Once established, the proxy then receives and forwards traffic bi-directionally between the client and service. The proxy makes all connection-establishment and packet-forwarding decisions; any routing functions that are active on the host system are generally irrelevant to the proxy.
As a final example of a security technique for operation in a firewall router, the terms stateful inspection or dynamic packet filtering refer to a more capable set of filtering functions on routers. Packet filtering is generally restricted to making its filtering decisions based only on the header information on each individual packet without considering any prior packets. Stateful inspection filtering allows both complex combinations of payload (message content) and context established by prior packets to influence filtering decisions. As with packet filtering, stateful inspection is implemented as an “add-on” to routing.
The principle motivation for stateful inspection is a compromise between performance and security. As a routing “add-on,” stateful inspection provides much better performance than proxies. It also provides an increase in the level of firewall function beyond simple packet filtering. Like proxies, much more complex access control criteria can be specified and like packet filtering, stateful inspection depends on a high quality (i.e., correct) underlying routing implementation.
Generally speaking, there are good reasons to use packet filtering, application proxies and/or stateful inspection, depending on the situation and needs of a particular user. For example, certain services (e.g., Simple Mail Transfer Protocol (SMTP), Hypertext Transfer Protocol (HTTP), or Network Time Protocol (NTP)) are usually safe to control via packet filters while others (e.g., Domain Name System (DNS), File Transfer Protocol (FTP)) may require the more complex features available only in proxies. Packet filtering is fast, while application proxies are generally slower. In cases where greater access control is required and the poorer performance of proxies cannot be tolerated, stateful inspection packet filters may be an acceptable compromise. In any case, if possible, it is advantageous to have as many of these different functions (i.e., packet filters, proxies, and stateful inspection) available as possible, applying each where appropriate.
Although there are many techniques for implementing and securing individual VPNs, as discussed above, there is an additional need for VPNs which can cross-communicate without sacrificing service to their users, e.g., without reducing the security of transmissions between the two (or more) VPNs or within a particular one of the VPNs.
In considering the difficulties associated with interconnecting multiple VPNs, then, it should be considered that a VPN is generally built to solve some common problems. These problems include, for example, virtualization of services and segregation of communications to a closed community of interest. Thus, when two different networks using the same or different VPN technologies are interconnected, the VPN Networks interconnecting function must respect at least the following principles: security of network operations, maintenance of network integrity, interoperability of services and data protection. Issues that arise from these principles include: scalability, complexity, security, cost of deployment and management.
Security, which can be implemented in various forms as already discussed, generally means preventing the hacking of packets, which may be snooped on, modified in transit, or subjected to traffic analysis by unauthorized parties. Additionally, security refers to avoiding misconfiguration errors that provide holes between two or more VPNs.
In inter-connecting different VPNs, whether a given VPN is behind a firewall device or not, some centralized VPN management tools enable secure connectivity between multiple customers and multiple services over a single connection, with flexible, centralized management and control. They simplify secure interconnection and management of networks with incompatible routing or address conflicts. They are generally limited to the type of equipment used and vendor. Such VPNs are centralized and have no secure feedback.
Such centralized configuration VPN systems allow the setting of network policies involving hardware devices, as well as user registration functions to set network policies and privileges. These conventional systems are based on what is known as an Access Control List (“ACL”).
ACL-based management systems essentially manage ACLs that are residing in routers that control traffic flow and provide some level of security of access. They can also perform the monitoring of user activity to determine when users are connected and where they're mapped, from a policy standpoint, to virtual LANs in the network. ACLs allow administrators to define security and traffic control policies for management across devices, according to the controlling company, and are also commonly used for securing Internet access. ACLs can be centrally managed through a template library. Access list configurations can be managed for groups of users and for devices and network services used in VPNs.
Conventional solutions for inter-connecting VPNs, especially non-centrally managed conventional solutions, are lacking in regards to global crosschecking of devices, support of any type of device being interconnected and interconnection with other tools such as security tools.
In addition, even if a VPN inter-connection technique is centralized, such conventional configurations use the same technology, i.e., ACLs that are downloaded to each device in the network. Thus, conventional ACL-based VPN solutions can be used for interconnections management only if the same tool is working on both types of VPNs being interconnected. Therefore, at least some manual ACL settings generally need to be implemented if a non-compatible protocol or piece of equipment is used.
Moreover, the centralized ACL configuration is static, and does not lend itself to automation. If another configuration tool is used, or a manual modification is performed by a user that has been granted access (or by a user who has mistakenly or illicitly gained access), there is no direct verification of the user and/or system done to check for errors or other problems.
An ACL may also take the form of a filtering statement in firewalls, but continue to use the same mechanism described above. Sometimes several similar rules are duplicated in cascaded equipments because there is a lack in confidence in what has been defined in other devices. ACL use has a high computing resources and performance impact on all devices, so that any simplification would improve network performance noticeably.
As a final point related to conventional techniques for cross-connecting devices on different VPNs, it is possible for administrators of, for example, a firewall router to maintain tables for managing the VPNs and cross-connections therebetween. However, such techniques are only workable for static configurations of VPNs, that is, the VPN(s) much be reconfigured and reset before a new transmission path can take place between the two VPNs. Therefore, these techniques are slow to implement, and are not easily scaleable. Moreover, such conventional techniques require knowledge of customer parameters by the administrator(s), and therefore may fail to maintain a desired level of privacy and security on the part of the VPN customer(s).
In short, no conventional approach currently exists which permits interconnection of VPNs in a secure, efficient, scaleable, reliable, dynamic and decentralized manner.